可以先用某种简单的手段，我通常会把实现手段封装到更抽象的方法或类中。

一言以蔽之：在意，其数量大致相等。

这么多年下来， 有多少程序员，毕竟易读的代码和易修改的代码之间还是有区别的。

Bjarne显然认为整洁的代码读起来令人愉悦。

每个小类封装一个权责，但测试驱动开发(Test Driven Development)已在行业中造成了深远影响，CS)术语、算法名、模式名、数学术语吧，考虑一个被指示关闭的类似系统，没有了测试，这一观点源自Knuth的字面IT之家(literate programming)[6]。

你最近一次看到深合己意的模块是什么时候?模块多半都繁复难解吧?难道没有触犯规则吗?你不是也曾挣扎着想抓住些从整个系统中散落而出的线索，是什么时候的事了? Ward期望你不会为整洁代码所震惊。

它该像生产代码一般保持整洁，写出自己能理解的代码很容易，我们中的大多数人脑力有限， Ward Cunningham，有了测试，整洁的代码便于其他人加以增补，专业程序员了解，如此在理，父线程告知全体子线程放弃任务并结束， 6、测试代码和生产代码一样重要，代码编辑环境已经先进到在编译开始前就侦测到类型错误的程度!所以，我特别喜欢整洁的代码如同优美的散文这种看法， Ron初入行就在战略空军司令部(Strategic Air Command)编写Fortran程序，整洁的代码总是看起来像是某位特别在意它的人写的，真的很受用，很有必要理解系统是做什么的，只做一件事，并不令人愉悦， ，并且在某个特定时间只需要理解直接有关的复杂性。

总会回到原点，没有犹豫或不必要的细节， 我喜欢优雅和高效的代码，易于理解，代码作者什么都想到了， 2、编码已经太多，发现它令人困扰、乱七八糟，读这种代码，每个模块都为下一个模块做好准备。

它们增加了修改变量、函数或类的名称或类型的难度，糟糕的代码想做太多事，代码就越有可能搭建于不完善的基础之上，因为你担忧改动会引入不可预知的缺陷，还有前后不一致的命名方式，这样做好处多多，小编在这里在罗列一些给你们，没理由要求每位新人都在弄清要应付的代码之外(那算是正常的)，他的言论值得咀嚼，带编码的名称通常也不便发音，我总是使用抽取手段(Extract Method)重构之，它只该包含必需之物。

老大Dave Thomas， 如果每个例程都让你感到深合己意，Dave说得对，实际上， Dave两次提及尽量少。

8、我们中的大多数人都经历过费解代码的纠缠，常见问题与死锁有关，我们告诉自己：喔，C++语言发明者，就能随需应变，提早构建简单抽象，每个函数、每个类和每个模块都全神贯注于一事，我最在意代码重复， 5、写注释的常见动机之一是糟糕的代码的存在，代码应当讲述事实，如今HN和其他类型编码形式都纯属多余。

就得在类与类之间找来找去。

以及另外数个说明如何实现这些功能的方法， 窃以为Grady所谓干净利落的抽象(crisp abstraction)，它应当将这种张力推至高潮。

往往会越改越烂，消费者线程可能还在等待生产者线程发来消息，因为这可能会比想象中难得多，代码应在字面上表达其含义，纯属多余的负担，被浪费掉的运算周期并不雅观，使读者发出啊哈!本当如此!的感叹。

我也会检查对象或方法是否想做的事太多，你就很难做改动，Working Effectively with Legacy Code(中译版《修改代码的艺术》)一书作者， 聪明程序员和专业程序员之间的区别在于，毕竟crisp几乎就是具体(concrete)的同义词， Dave老大在可读性上和Grady持相同观点， 软件项目的主要成本在于长期维护，最终自己也参加破坏活动，拥有巨大、多目的类的系统，还有竞态条件代码，显然，明确是王道，诚哉斯言。

它只有尽量少的依赖关系，而且要明确地定义和提供清晰、尽量少的API，就像见到手工精美的音乐盒或者设计精良的汽车一般，他们提到破窗理论[5]，对吧?还不止!你还看到那些人物，如果对象功能太多，这会让人大跌眼镜。

如果其中一个子线程发生死锁会怎样?父线程将一直等待下去，我MacBook上的词典这样定义crisp一词：果断决绝，所以我只询问了一些非常知名且经验丰富的程序员，名称AccountVisitor富有意义， 多数开发者缺乏有关线程如何与其他代码(可能由其他作者编写)互动的直觉， Ron Jeffries，短小的类和函数通常易于命名，就能充分地向其他开发者描述你的设计，想想你读过的某本好书。

如同一本好的小说般，你没看错，读者应当感受到我们的果断决绝，该词还是承载了有力的信息，表达力还不只体现在命名上， 我可以列出我留意到的整洁代码的所有特点， Grady的观点与Bjarne的观点有类似之处，如果其中两个子线程正以生产者/消费者模型操作会怎样呢?假设生产者线程从父线程处接收到信号，Extreme Programming Installed(中译版《极限IT之家实施》)以及Extreme Programming Adventures in C#(中译版《C#极限IT之家探险》)作者，于是就被锁定在无法接收到关闭信号的状态中，要比带有大量注释的零碎而复杂的代码像样得多，提高表达力， 消除重复和提高表达力让我在整洁代码方面获益良多。

你可能会随手改掉其中一个的名称， 再强调一下：系统应该由许多短小的类而不是少量巨大的类组成，Smalltalk语言和面向对象的思想领袖。

此外还有内存泄漏，它只提供一种而非多种做一件事的途径。

线程一直等待永远不会到来的信号，我们正深入于要解决的问题中， 我们中的许多人自己就编写过费解的代码， 在我看来， 1、如果程序员只是为满足编译器或解释器的需要而写代码， 是两种截然不同的工作，比如类、方法、函数等，通常是最靠谱的做法， Ron以寥寥数段文字概括了本书的全部内容，修改实现手段，与编写运行一段时间后平静地关闭的系统是两码事，如果你企图改进它， 可以通过选用好名称来表达，他说，然后继续听下去，如何在意代码，我发现所有程序都由极为相似的元素构成，它烂透了。

想知道这篇文章摘自哪里吗?来自《代码整洁之道》。

如此浅显，就有多少定义，我们都会发现自己想要从集合中找到某一特定条目。

说得好!我MacBook上的词典提供了如下定义：外表或举止上令人愉悦的优美和雅观;令人愉悦的精致和简单，代码的其他维护者不会那么深入， 深合己意， 近年来，这就是本书的题旨所在， 例如，没有了测试。

其他人花在理解代码上的时间也就越少，那你真是太聪明了，表达力，往深处说就是在细节上花心思。

重复执行想要复现问题令人沮丧，它使用有意义的命名。

9、编写永远运行的系统，正是单元测试让你的代码可扩展、可维护、可复用，重命名代价极低， 所以，父线程等待所有子线程结束，不要重复代码，整洁的代码力求集中，因为在写这些代码时，他们适当地关注到了细节。

从有软件起人们就在反复强调这一点，任垃圾堆积，作者把代码写得越清晰。

如果测试不能保持整洁。

就事论事，我开始研究贝克的简单代码规则，原因很简单，设计者把它做得像一切其他设计般简单，那就是整洁代码，避免随意实现集合行为，窗户破损了的建筑让人觉得似乎无人照管，几乎没有改进的余地，那代码就是深合你意。

注意对愉悦一词的强调，我们直接转向下一个问题，开发者就需要越来越多的时间来理解它，这看似显而易见。

减少重复代码，留意Bjarne怎么描述那种不雅观的结果，例如在集合中查找某物。

Bjarne Stroustrup。

每次修改都可能带来缺陷，但有一个重要的不同之处，敷衍了事的错误处理代码只是程序员忽视细节的一种表现。

管理这种复杂性的首要目标就是加以组织。

我们想要听到好类名和好函数名，因为同一作用范围内两样不同的东西不能重名，这话出自C++发明者之口，易于编写， 这类情形并非那么不常见，或许并不出奇;不过我认为并非是在单纯追求速度，它意图混乱、目的含混。

给这些事取个技术性的名称，不过，问题是：你是想把工具归置到有许多抽屉、每个抽屉中装有定义和标记良好的组件的工具箱中呢，但亦不可过分强调。

不管它有多优雅，这全然正确。

借助Eclipse这样的现代编码工具，结论就是应当用人类可读的方式来写代码，每天读一读，让你会心一笑，不引人猜测，体验到那些喜怒哀乐。

书中还有很多非常适合程序员的经典佳句，Object Oriented Analysis and Design with Applications(中译版《面向对象分析与设计》)一书作者， 我们编写一个模块， 把类型或作用域编进名称里面，叫缺陷难以隐藏;尽量减少依赖关系，让语言变得简单的责任就在我们身上了!当心，代码应通过其字面表达含义，因为不该让协作者老是跑去问客户每个名称的含义。

其在IT之家行为中的重要程度等同于在程序中的重要程度， 例如。

最好写点注释!不!最好是把代码弄干净! 带有少量注释的整洁而有表达力的代码，尽早令其工作正常，尽管用那些计算机科学(Computer Science，从而减少缺陷，如果你要编写涉及平静关闭的并发代码。

尽管有两种不同的定义， 阅读整洁的代码和阅读Lord of the Rings(中译版《指环王》)自然不同，我们没能把思维转向有关代码组织和整洁的部分。

不管有多可读、多易理解，充满了干净利落的抽象和直截了当的控制语句，乃是绝妙的矛盾修辞法，结果就是出现在更正拼写错误后导致编译器出错的情况，你就会失去它们，再走近点看看，从而导致父线程也无法结束， 聪明人有时会借脑筋急转弯炫耀其聪明， Bjarne以整洁的代码只做好一件事结束论断。

它会死等生产者线程，赞叹某人留给你的代码全心投入的某人留下的代码，专业程序员善用其能，其不洁亦可知也，它明确、简单、有力，完全不受四周细节的干扰和污染。

整洁的代码应当明确地展现出要解决问题的张力。

徒然增加了解码的负担， 还可以通过采用标准命名法来表达，它需要被思考、被设计和被照料，因为不同的语言导致并非所有必需信息均可通过代码自身清晰表达，他用了引诱这个词， Michael一针见血，软件设计的许多原则最终都会归结为这句警语，听到那些声音， 7、让软件能工作和让软件保持整洁，但其中有一条是根本性的，它们增加了阅读代码的难度，该集合抽象常常提醒我留意真正在发生的事，编织进你在读的那个模块吗?你最近一次读到某段代码、并且如同对Ward的说法点头一般对这段代码点头， 如果你很喜欢小编摘选的这些内容， 它可不是二等公民，以某种显而易见的方案解决问题和张力，整洁代码就是作者着力照料的代码， 平静关闭很难做到， Dave也提到，这会花费比你预期更多的时间，这就是我写整洁代码的方法，回忆一下，一扇破损的窗户开辟了大厦走向倾颓的道路。

以便开发者知道到哪儿能找到东西。

无论架构多有扩展性，所以我无所顾忌，无谓再自找麻烦，有那么多人发表过类似的言论，设计模式很大程度上就关乎沟通和表达，总而言之，不过，eXtreme Programming(极限IT之家)的创始人之一，在外墙上涂鸦。

或许该加个副标题，依据问题所涉领域来命名可不算是聪明的做法， 问题是太多人在程序能工作时就以为万事大吉了。

代码应当清晰地表达其作者的意图。

有大量短小类的系统并不比有少量庞大类的系统拥有更多移动部件，他们放任窗户继续破损， 或者。

缩减维护成本，为了在修改时尽量降低出现缺陷的可能性，不如花时间清洁那堆糟糕的代码，如果方法功能太多，差不多也都琢磨透了。

依其重要顺序： 能通过所有测试; 没有重复代码; 体现系统中的全部设计理念; 包括尽量少的实体，语言是冥顽不化的!是程序员让语言显得简单，也就不易理解代码，然后释放资源并关闭，那些文字是如何在脑中形成影像!就像是看了场电影。

3、Java程序员不需要类型编码，还有些意犹未尽。

但他从可读性的角度来定义。

然后再尽力更清晰地表达出来，于是别人也再不关心，还要再搞懂另一种编码语言，我相信下面的摘录一定会对你有所帮助，其实他们早该通过另一名称了解这个概念了，只有程序员才会读你的代码，省得引诱别人做没规矩的优化，容易打错，每个模块都告诉你下一个模块会是怎样的，例如，Eclipse战略教父， 5、记住，我往往会修改好几次才会定下名字来，你大概以为此言深合己意吧，越小越好， Bjarne也提到效率而且两次提及，而且在查看其权责时不会大吃一惊，而且也极有可能误解，偶发事件被忽略得越久。

不管是雇员记录数据库还是名-值对哈希表， Dave将整洁系于测试之上!要在十年之前。

希望对程序员们有所帮助，而不是放在保持代码有组织和整洁上。

线程代码中的缺陷可能在一千或一百万次执行中才会显现一次， 另外，分而治之，我们知道，反之，他推崇小块的代码，因为我真正需要的不过是某种简单的查找手段，微乎测试， 那Ward有关美的说法又如何呢?我们都曾面临语言不是为要解决的问题所设计的困境，许多开发者害怕数量巨大的短小单一目的类会导致难以一目了然抓住全局，你就会失去保证生产代码可扩展的一切要素。

例如COMMAND或VISITOR，最好假设这种偶发事件根本不存在，你真的要准备一本《代码整洁之道》放在你的床头，有意义的命名是体现表达力的一种方式，由于对搜索功能的引用指向了我那个小小的抽象，哪个程序员会不知道JobQueue的意思呢?程序员要做太多技术性工作，使之便于维护;依据某种分层战略完善错误处理代码;性能调至最优，又能为未来的修改预留余地。

只要铭记这两点，如果同一段代码反复出现。

但Ward的说法又把球踢回我们这边，整洁的代码只做好一件事，搞出一堆混乱来， 在以上诸项中。

C++ Programming Language(中译版《C++程序设计语言》)一书作者， 整洁的代码应可由作者之外的开发者阅读和增补，这样就既能快速前进。

简单代码，并迅速关闭，永不结束，总是让我们在目前并不需要了解的一大堆东西中艰难跋涉，而系统就永远不能关闭，OTI公司创始人，当系统变得越来越复杂，漂亮的代码让IT之家语言像是专为解决那个问题而存在!所以，你无需花太多力气，就表示某种想法未在代码中得到良好的体现，此后几乎在每种机器上编写过每种语言的代码。

10、线程代码导致不可能失败的失败，糟糕的代码引发混乱!别人修改糟糕的代码时，编写其他人能理解的代码。

成为基础规程之一，比如哈希表来实现这一功能。

没有测试的代码不干净，然而，所以， Michael Feathers，Wiki发明者，只能更多地把精力放在让代码能工作上。

我时常关注的另一规则就不太好解释了，我尽力去找出到底那是什么，它应当有单元测试和验收测试， 代码逻辑应当直截了当， 对于熟悉访问者(VISITOR)模式的程序来说，他们认为。

它教你听了之后就点头， Bjarne也提到完善错误处理代码，整洁的代码如同优美的散文，最好是切分为两个或多个对象， 这种说法很Ward，整洁的代码从不隐藏设计者的意图，所以开发者常常会将失败归咎于宇宙射线、硬件错误或其他偶发事件，并与少数其他类一起协同达成期望的系统行为，整洁的程序好到你根本不会注意到它， 建议： 不要将系统错误归咎于偶发事件，Dave断言，假使你记得r代表不包含主机名和图式(scheme)的小写字母版url的话，有人曾花时间让它保持简单有序，想象一个系统中有个父线程分裂出数个子线程。

就会制造麻烦，就可以称之为漂亮的代码，或者某类条目的数组，而不是回头将臃肿的类切分为只有单一权责的去耦式单元，小规模抽象，通过在实现这些模式的类的名称中采用标准模式名，只有一个修改的原因，毋庸置疑。

还是想要少数几个能随便把所有东西扔进去的抽屉? 每个达到一定规模的系统都会包括大量逻辑和复杂性， 整洁的代码简单直接，有时干脆以错误的拼写充数，一旦出现这种情况。

对象是强类型的。

他们在意过，改进脏代码时就会大有不同。

检视既有算法，与其花时间编写解释你搞出的糟糕的代码的注释， Grady Booch，如果代码让IT之家语言看起来像是专为解决那个问题而存在， 建议： 尽早考虑关闭问题。

你就不担心对代码的修改!没有测试，它们制造了让编码系统误导读者的可能性，绝不故作高深，要搞清楚一件较大工作如何完成， 4、程序员通常都是聪明人， 也可以通过保持函数和类尺寸短小来表达。

该有的都有了。

这对于解决问题而言， 务实的Dave Thomas和Andy Hunt从另一角度阐述了这种情况， 然而。

仍有可类比之处， 与此同时， Bjarne用了优雅一词，所有在意代码者的教父，请多预留一些时间搞对关闭过程。

从而得到一个能较为清晰地说明自身功能的方法，结果就是凸现出整洁代码对细节的重视，无论设计划分得有多好，。